The present invention relates to an application-programming model using software objects, and more particularly relates to maintaining security in object-based applications.
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations.
In a server application that is used by a large number of people, it is often useful to discriminate between what different users and groups of users are able to do with the server application. For example, in an on-line bookstore server application that provides processing services for entering book orders, order cancellations, and book returns, it may serve a useful business purpose to allow any user (e.g., sales clerk or customers) to access book order entry processing services, but only some users to access order cancellation processing services (e.g., a bookstore manager) or book return processing services (e.g., returns department staff).
Network operating systems on which server applications are typically run provide sophisticated security features, such as for controlling which users can logon to use a computer system, or have permission to access particular resources of the computer system (e.g., files, system services, devices, etc.) In the Microsoft Windows NT operating system, for example, each user is assigned a user id, which has an associated password. A system administrator also can assign sets of users to user groups, and designate which users and user groups are permitted access to system objects that represent computer resources, such as files, folders, and devices. During a logon procedure, the user is required to enter the user id along with its associated password to gain access to the computer system. When the user launches a program, the Windows NT operating system associates the user id with the process in which the program is run (along with the process"" threads). When a thread executing on the user""s behalf then accesses a system resource, the Windows NT operating system performs an authorization check to verify that the user id associated with the thread has permission to access the resource. (See, Custer, Inside Windows NT 22, 55-57, 74-81 and 321-326 (Microsoft Press 1993).)
A thread is the basic entity to which the operating system allocates processing time on the computer""s central processing unit. A thread can execute any part of an application""s code, including a part currently being executed by another thread. All threads of a process share the virtual address space, global variables, and operating-system resources of the process. (See, e.g., Tucker Jr., Allen B. (editor), The Computer Science and Engineering Handbook 1662-1665 (CRC Press 1997).)
The Windows NT operating system supports an application execution environment called Microsoft Transaction Server, a product separate from Windows NT which allows developers to define access control to processing services of an application independently of deployment during development using roles. Roles are logical groups of users that can be assigned at development time, and independent of a specific operating system security configuration until deployment. Subsequently, at deployment time, an administrator can bind the roles to particular users or user groups, resulting in a mapping of roles to users.
At execution time, Microsoft Transaction Server monitors cross process calls at the object and interface level to determine if the caller is a member of a role permitted to make the call. If the caller is not permitted access, the call is blocked, preventing access to the object""s functionality by unauthorized users.
However, a problem can arise if two objects with different security requirements execute in the same process. For example, a first object might allow access by anyone, and a second object in the same process might allow access only by a select group. Since Microsoft Transaction Server checks only inter-process (i.e., cross-process) calls, a call could enter a process through the first object legitimately granting access to the caller. While doing work for the caller, the first object might call the second object for which the caller does not have access rights. Nevertheless, since security checks are made only for inter-process calls, the call could effectively circumvent the security services, having obtained unauthorized access to the functionality of the second object.
One way to prevent callers from circumventing the security system is to place each object in a separate process, ensuring that a security check is made for all calls between objects. However, each additional process consumes additional system resources, and cross process calls require invocation of additional logic consuming even more system resources. Therefore, placing every object in a separate process is expensive in terms of computing resources.
Another way to prevent callers from circumventing the security system is to place logic in the object to verify role membership before allowing calls to certain other objects. A disadvantage to such an approach is that object developers are burdened with incorporating security logic into their objects, and changing the logic requires rewriting and recompiling the application objects.
The present invention includes a security framework for controlling access to objects providing processing services in a server application. The security framework provides for intra-process access checks on calls to objects, thereby avoiding the need to place objects in different processes to enforce security boundaries. Access checks are done transparently to the application objects, freeing the application developer from having to incorporate security logic into the application objects.
In one aspect of the invention, a developer can declaratively define security requirements such as authorized users for calls to objects and a minimum acceptable authentication level for an application. The security framework tracks and enforces the requirements transparently to the objects, again freeing the application developer from including security-enforcing logic in the object.
A further aspect of the invention supports method-level security, allowing developers to declaratively define authorized users and authentication levels for particular methods, interfaces, or objects. Again, the developer is freed from having to incorporate logic in the object (i.e., in a particular method) to check security.
In yet another aspect of the invention, an application developer can declaratively define the security scheme using a graphical user interface depicting application objects, interfaces, and methods. The security settings defining the security scheme reside in a central store outside the application objects.
Another aspect of the invention supports role-based security in combination with intra-process security boundaries. Role-based security allows user identities to be defined independently of specific users during development of the application.
In another aspect of the invention, a security boundary is placed between objects of different applications, facilitating integration of multiple applications.